Minimal Viable Plasma における confirmation

---.icon

confirm sig の役割

The confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.

（Alice が Bob に送金したという前提）

---.icon

confirm sig を公開するタイミング

The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.

denett：challengeExit 関数は confirm sig を要求する。confirm sig は全ての Plasma 参加者にブロードキャストされるのであれば、全員が全ての不正な exit に対して challenge できる。

The signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.

vbuterin：confirm sig は全ての Plasma 参加者にブロードキャストされるわけではない。なぜなら、ブロードキャストしないことでシステムを邪魔できてしまうから。正しくは以下。UTXO を受け取った人は、その UTXO を使用する際にその UTXO に対する confirm sig を公開する必要がある。

If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.

---.icon

confirm sig と challenge の関係

So if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.

denett：Alice が Plasma コインを Bob に送った場合、まず Bob だけが Alice の exit に challenge できる。Bob が送られてきた Plasma コインを使った後に confirm sig は公開され、誰でも challenge できるようになる。Bob がまだ Plasma コインを保持している（Bob 以外が confirm sig を知らない）状態において、Alice の exit に対する challenge が失敗したら、Bob は罰され、もう Plasma コインを使うことはできなくなるだろう。

I don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.

denett：このようなケースにも既存の challengeExit 関数を使うことができるのか、もしくは、依存するトランザクションが既に exit されていることの証明を提出して challenge するための新しい関数をコントラクトに追加する必要があるのか、自分にはわからない。

Alice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.

denett：Alice が Bob に confirm sig を送る。例えば、プライベートでメールで送るなど。Alice が exit しようとした場合、Bob はこの confirm sig を使って Alice の exit に challenge できる。Bob が次のトランザクションをつくる際にも confirm sig が必要。Bob のトランザクションによって confirm sig は Plasma チェーンに含められ、公開される。これで、Plasma チェーンを見ている人は全員 Alice の exit に challenge できるようになる。

---.icon

confirm sig の保持

One thing that Plasma spec does not specify exactly is who stores which signatures. May be one can edit the description at the beginning of this thread to specify this.

kladkogex：Plasma の仕様において正確に定義されていないことの 1 つは、誰が confirm sig を保持するかである。これを定義するために誰かがこのスレッドの冒頭で提案された説明を編集するかもしれないが。

Lets consider an example where

1. Alice deposits 1000 dollars and creates a 100,000 transactions each time paying 1 cent to herself.

2. In process of doing so Alice generates 100,000 confirmation signatures (several megabytes of data).

kladkogex：以下のような例を考えてみたい。

1. Alice は 1,000 ドルをデポジットし、自身に 1 セントずつ送ることで 100,000 トランザクションを生成する

2. 1 の過程において、Alice は 100,000 個の confirm sig（数 MB のデータ）を生成する

The question is

a) are these signatures stored longterm by any party except Alice?

It seems that unrelated people will have little incentive to store these signatures.

b) If no-one stores these intermediate signatures, then it seems like Alice can exit all the intermediate UTXOs without a challenge (since to maintain a challenge it seems that one is required to present the signature? The challenge function does require a signature as one of its arguments. If Alice was dealing with herself to create a chain of self-dealing UTXOs, I am not sure who the party will be that will possess the signatures …

kladkogex：疑問点は以下。

a) これらの confirm sig は Alice 以外の誰かによって長期間保持されるのか？

無関係な人々が confirm sig を保持するインセンティブほとんどないように思える

b) 誰もこれらの confirm sig を保持しなかった場合、Alice は全ての UTXO を challenge を受けずに exit できるということ？

challenge には confirm sig を提示する必要がある

実際、challenge function はその引数として confirm sig を要求している

Alice が自身と取引するようなトランザクションを連鎖させた場合、誰がそれらの confirm sig を保持するのか分からない

The original Plasma paper required these signatures to be broadcast onto the Plasma chain, so you’d avoid (2) at a large data cost to everyone. In your example (off-chain conf sigs), Alice must reveal the one conf sig to spend the next, but this is also broken if Alice is coordinating with the operator, unless these conf sigs must be published on-chain to spend, but then we’re basically back at what the original paper called for.

kfichter：オリジナルの Plasma ペーパーでは、confirm sig は Plasma チェーン上にブロードキャストする必要があるとされているので、大きなデータ保持コストを全員が担うことで b) を避けることはできる。上記の例（オフチェーンな confirm sig）において、Alice は confirm sig を公開しないと UTXO を使えないが、confirm sig がオンチェーンで公開されない限り、これも Alice がオペレータと共謀していれば破綻する。よって、結局はオリジナルのペーパーが要求していることに戻ってくる。

Basically, you’re right, it’s why I’m trying to get rid of confirmation signatures entirely.

kfichter：基本的に kladkogex の指摘は正しい。ゆえに我々は confirm sig を完全に取り除こうとしている。